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METHOD FOR GUIDING REPAIR OR REPLACEMENT 
OF PARTS FOR GENERALLY COMPLEX EQUIPMENT 

This application is a continuation-in-part of U.S. Patent Application 
Serial No. 09/644,421 and further claims the benefit of U.S. Application 
Serial No. 60/258, 747. 

BACKGROUND OF THE INVENTION 

This invention relates to method and system for servicing generally 
complex equipment, and, more particularly, to computer-based method 
and system for guiding servicing or replacing of parts of any selected 
equipment. 

The diagnosis, maintenance, and repair of generally complex 
equipment, such as mobile assets including on-road or off-road vehicles, 
ships, airplanes, railroad locomotives, trucks, and other forms of complex 
equipment including industrial equipment, consumer appliance 
equipment, medical imaging equipment, equipment used in industrial 
processes, telecommunications, aerospace applications, power generation, 
etc., involves extremely complex and time consuming processes. In the 
case of transportation equipment, efficient and cost-effective operation of a 
fleet of vehicles necessitates a reduction in the number of vehicle road 
failures and minimization of vehicle down-time. This can be accomplished 
by predicting impending failures, by performing preventative 
maintenance, and by performing repairs quickly and accurately. For 
example, it will be appreciated that the ability to predict failures before 
they occur allows for performing condition-based maintenance. Such 
maintenance can be conveniently scheduled based on statistically and 
probabilistically meaningful vehicle status information, instead of 
performing the maintenance regardless of the actual condition of a 
respective system, subsystem, assembly, subassembly, part, etc., such as 
would be the case if the maintenance is routinely performed independent 



of whether any of the foregoing structures actually requires the 
maintenance. 

The conventional diagnosis and repair process for most vehicles and 
other generally complex equipment is based on the experience of the 
5 service technician, using paper-based information describing the structure 
and operation of the equipment, and performance records maintained in a 
log. Examining the log entries, experienced service technicians can use 
their accumulated experience and training in mapping incidents occurring 
in locomotive systems, subsystems, assemblies, subassemblies, etc., to 
10 problems that may be causing these incidents. For simple problems, this 
process works well. However, if the problem is complex and the root cause 
difficult to discern, the experienced technician may be unable to identify 
the problem and certainly much less likely to prognosticate problems 
before they occur. 

15 Various equipment often incorporates diagnostic controls and 

sensors that report faults when anomalous operating conditions of the 
equipment arise. Typically, to diagnose the problem, a technician will 
study the fault log to identify the nature of the problem and determine 
whether a repair is necessary. While the fault log can provide some 

20 diagnosis and repair information, the technician also relies substantially 
on his prior experiences with the equipment, or others like it, to make a 
full diagnosis. 

To conduct the repair, the technician uses block diagrams, exploded 
diagrams, parts lists, assembly drawings, schematics, etc. The repair 
25 information may be applicable only to a specific equipment by model 
number; the repair information will generally not be unique to the specific 
equipment undergoing repair. It will be apparent that as the complexity 
of the equipment increases, the amount of paper needed to describe the 
equipment to assist with the repair process likewise increases. Again, the 
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technician will rely on his experiences with the equipment, and others like 
it, to perform the repair. 

Yet another problem with a paper-based system is the variety of 
field-deployed equipment configurations, each having its own unique 
5 technical support documentation. In the case of locomotives, even for a 
specific model (identified by a model number), there may be several 
locomotive configurations as locomotive subsystems were redesigned or 
changed during the model production run. Thus, in a sense, no two 
locomotives are the same. Adding this configuration complexity to a 
10 paper-based system presents an inordinately complex and unmanageable 
problem of locating the correct technical repair documentation for a 
specific locomotive. 

Another repair issue involving complex equipment, such as railroad 
locomotives or other mobile or stationary assets, is the unavailability of a 
15 repair history from which one could predict component failures and 
undertake preventative maintenance beforehand. Technicians with wide 
ranging and lengthy experiences may be able to predict a component 
failure and repair it to avoid a breakdown during operation, in some 
limited situations. 

20 One tool available for locomotive repair manually downloads fault 

logs from a locomotive while it is parked at a maintenance facility. These 
fault logs are then uploaded to the railroad maintenance service center. 
The tool also includes standardized helpful hints for repair tasks and fault 
analysis descriptors based on single failure faults. Although such a device 

25 represents an improvement over a paper-based system, it falls short of the 
informational needs for a complex equipment, such as a locomotive, and 
fails to advantageously utilize the various technologies available for more 
efficiently predicting and performing the repair. 

The techniques of the present invention in one aspect thereof may 

30 be useful in identifying and ordering replacement parts for complex 
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equipment having multiple configurations. For example, while 
locomotives are routinely sold under particular model numbers, each 
locomotive is typically customized for a particular application or customer. 
Consequently, when a user needs to identify replacement or repair parts 
5 or check on upgrades for a particular locomotive, it is often difficult for 
that user to particularly identify the needed part or upgrade without 
knowing more about the particular locomotive. In many instances, the 
user may not know the particular parts or level of upgrade of a locomotive 
that is in use. However, manufacturers of locomotives generally keep 

10 detailed records of the status of each part or assembly or sub-assembly of a 
locomotive during manufacture and also track upgrades to that locomotive 
since such upgrades are normally done by purchase of upgrade kits from 
the original manufacturer. Accordingly, it is common for a locomotive user 
to contact the locomotive manufacturer in order to identify replacement 

15 parts or upgrades for a locomotive. Thus, it would be advantageous for 
service personnel to have access via a communications network to detailed 
information concerning the parts content or upgrade status of any selected 
equipment that may be ready to undergo a servicing activity. 

BRIEF SUMMARY OF THE INVENTION 

20 Generally, the present invention fulfills the foregoing needs by 

providing in one aspect thereof a computerized method for guiding 
equipment service personnel while at an equipment work site through a 
plurality of tasks for troubleshooting the health of a selected system of a 
selected equipment to determine the nature and extent of service needed 

25 for such system. The method provides a database comprising detailed 
data for health assessment and servicing of a selected equipment and 
system thereof, and an expert rule-based troubleshooting wizard for 
eliciting information regarding the selected equipment and system and for 
providing troubleshooting instructions to determine the nature of the 
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for such system. The method provides a database comprising detailed 
data for health assessment and servicing of a selected equipment and 
system thereof, and an expert rule-based troubleshooting wizard for 
eliciting information regarding the selected equipment and system and for 
5 providing troubleshooting instructions to determine the nature of the 
equipment fault and the servicing required for the selected equipment and 
system. An input/output device at the work site for communicating with 
the database is provided. The method further provides for selecting the 
equipment and the system thereof to be serviced and for accessing the 

10 database to interface with the troubleshooting wizard for the selected 
equipment and system. The method also provides in response to a set of 
prompts to the personnel from the troubleshooting wizard at least one set 
of observations selected from the group comprising operational 
performance of the selected equipment, operational performance of the 

15 selected system, and fault indications detected in the equipment and 
system. The method processes the observation information relative to the 
troubleshooting wizard to determine whether or not said selected 
equipment and system needs to be serviced, and if so the nature and 
extent of that service. 

20 The present invention further fulfills the foregoing needs by 

providing in another aspect thereof a computerized system for guiding 
equipment service personnel while at an equipment work site through a 
plurality of tasks for troubleshooting the health of a selected system of a 
selected equipment to determine the nature and extent of service needed 

25 for such system. The system includes a database comprising detailed data 
for health assessment and servicing of a selected equipment and system 
thereof, and an expert rule-based troubleshooting wizard for eliciting 
information regarding the selected equipment and system and for 
providing troubleshooting instructions to determine the nature of the 

30 equipment fault and the servicing required for the selected equipment and 
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system. An input/output device is provided at the work site for 
communicating with the database and selecting the equipment and the 
system thereof to be serviced. A data management module is configured to 
access the database to interface with the troubleshooting wizard for the 
5 selected equipment and system. The data management module also 
supplies, in response to a set of prompts to the personnel from the 
troubleshooting wizard, at least one set of observations selected from the 
group comprising operational performance of the selected equipment, 
operational performance of the selected system, and fault indications 
10 detected in the equipment and system. A processor configured to process 
said observation information relative to the troubleshooting wizard to 
determine whether or not said selected equipment and system needs to be 
serviced, and if so the nature and extent of that service is also provided. 



BRIEF DESCRIPTION OF THE DRAWINGS 
15 The present invention can be more easily understood and the 

further advantages and uses thereof more readily apparent, when 
considered in view of the description of various exemplary embodiments 
and the following figures in which: 

Figure 1 is a pictorial rendering of an exemplary system that may 
20 be used for practicing aspects of the present invention; 

Figure 2 is a block diagram showing exemplary subsystems for the 
system of Figure 1; 

Figure 3 is a pictorial rendering showing exemplary elements of a 
wireless embodiment in accordance with one aspect of the present 
25 invention; 

Figure 4 is an exemplary screen display of a portable unit such as 
may used to implement aspects of the present invention; 

Figures 5 and 6 are respective flow charts illustrating an exemplary 
repair process for a given equipment; 
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Figure 7 is a block diagram of exemplary components of a system 
constructed according to aspects of the invention; 

Figure 8 is a flow chart of an exemplary example of a trouble 
shooting wizard; 

5 Figure 9 is a process flow chart showing operational details of 

aspects of the present invention; 

Figure 10 is a block diagram of exemplary components of a system 
constructed according to aspects of the invention; and 

Figure 11 is a process flow chart showing operational details of 
aspects of the present invention. 
DETAILED DESCRIPTION OF THE INVENTION 

Before describing in detail various aspects of the present invention, 

10 it should be observed that the present invention broadly comprises a novel 
combination of processing steps/actions and/or hardware/software 
configured to quickly and reliably meet the servicing needs of generally 
complex equipment that may comprise multiple generally interrelated 
systems, assemblies, subassemblies, parts, etc. Accordingly, these 

15 processing steps/actions and hardware/software components have been 
represented by generic processes and elements in the drawings, showing 
only those specific details that are pertinent to the present invention, so as 
not to obscure the disclosure with structural details or operational 
interrelationships that will be readily apparent to those skilled in the art 

20 having the benefit of the description herein. 

Figure 1 is a schematic representation of an exemplary system that 
may benefit from the techniques of the present invention. Although 
illustrated and described with respect to a railroad locomotive 12, those 
skilled in the art will understand that the teachings of the present 

25 invention are applicable to many types of equipment, including those 
which may be part of a large fleet, such as trucks, ships, off-road vehicles, 
airplanes, etc. The locomotive 12, such as may be parked at a railroad 
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service yard 13, may be serviced by a technician or other service personnel 
holding a portable unit 14. In one embodiment, the portable unit 14 
communicates with a railroad service shop 16 including an antenna 18 via 
any of various well-known wireless or wired communication systems and 
5 protocols, including an Internet connection using the TCP/IP protocols, 
tone modems, ISDN or XDSL protocols over the public switched telephone 
network or a cable modem. In one exemplary embodiment, access may be 
provided to information gathered at a monitoring and diagnostic service 
center 20 (MDSC) via a communications network, such as the Internet. It 

10 will be appreciated that other network configurations may be used. For 
example, an intranet including the portable unit 14, the service shop 16 
and the MDSC 20 can be used to provide communications between these 
devices. It will be appreciated that the present invention is not limited to 
embodiments interconnected to the MSDC 20 since many of the 

15 techniques of the present invention can be implemented independently of 
MSDC 20. It will be further appreciated that the techniques of the 
present invention are not limited to embodiments using a portable unit 
since it is contemplated that other communication or input/output device, 
such as a kiosk, computer terminal, or other computer peripherals may be 

20 used for enabling the various communications interrelationships described 
below. 

Repair, maintenance, and diagnostic information is exchanged 
between the portable unit 14 and the MSDC 20 via the railroad service 
shop 16. Parts information is exchanged between the portable unit 14 and 

25 a parts requisition center 22. Further, contractual information, such as 
warranty information, is exchanged with a customer center 24. Generally, 
the parts requisition center 22, the customer center 24, and the MDSC 20 
are located remote from the service shop 16 and the service yard 13. The 
requisition center 22, the customer center 24, the MDSC 20, and the 

30 service shop 16 may be linked via a global information network, such as 
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the Internet and the World Wide Web, via an intranet or by point-to-point 
communications system, examples of which are discussed above. Because 
the Internet provides the ability to communicate data and information in a 
multimedia format, it is especially useful for communicating and 
5 displaying the large amount of data associated with the repair, 
maintenance and diagnosis of the locomotive 12. 

Note that in another embodiment, the portable unit 14 can 
communicate directly (via a wired or wireless system using any of the 
communications techniques discussed above) with the parts requisition 

10 center 22, the customer center 24 and the MDSC 20, rather than 
communicating through the service shop 16. The portable unit 14 can also 
interrogate an on-board monitoring and diagnostic system (not specifically 
shown in Figure 1) of the locomotive 12. The on-board monitoring and 
diagnostic system is described in detail in the patent application entitled 

15 "On-Board Monitor for a Railroad Locomotive", application number 
09/696,368, filed on October 25, 2000, (Attorney docket number 
624226.133/20-LC-1978), which is assigned to the owner of the present 
invention. The on-board monitor monitors certain operational parameters 
on the locomotive 12 and reports faults and anomalous conditions directly 

20 to the MDSC 20 via an independent communications system, as described 
in the aforementioned patent application. 

While at the locomotive, the technician, using his portable unit 14, 
has access to a plethora of repair, diagnostic, and operational information 
needed to efficiently and accurately trouble shoot locomotive problems and 

25 undertake the necessary repairs. The portable unit 14 downloads repair 
recommendations generated by analysis software and/or locomotive repair 
experts at the MDSC 20. From the portable unit 14, the technician also 
has access to repair resources, such as repair manuals, field modification 
instructions, schematics, block diagrams, etc. Special software tools 

30 related to the repair task are also available at the portable unit 14, as 
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transmitted from the diagnostic service center 20. The portable unit 14 
allows easy and seamless integration of the repair recommendation with 
the railroad's work order system as managed and controlled at the service 
shop 16. The system provides parts ordering and parts tracking via 
5 communications with the parts requisition center 22. Repair experts at 
the monitoring and diagnostic service center 20 can also provide 
individualized assistance to the technician via the portable unit 14, using 
an instant messaging feature incorporated therein. Problem resolution 
suggestions and repair actions can be created prior to access by the repair 

10 technician or they can be authored in real time by experts at the 
monitoring and diagnostic service center 20 and immediately transmitted 
to the portable unit 14. The repair technician can also provide visual 
information back to the monitoring and diagnostic center 20 (over an 
Internet connection, for example) using a camera attached to the portable 

15 unit 14. Still or video images can be provided by such a camera. The 
video information may also be accompanied by live audio information (as 
spoken by the technician), thereby allowing the technician to communicate 
with personnel at the monitoring and diagnostic service center 20 to confer 
about a particular problem or repair action. In those cases where the 

20 locomotive components include a bar code for encoding certain features or 
characteristics of the component, a bar code reader attached to the 
portable unit 14 can be used to decode the bar code information and 
transmit the decoded information (or the bar code itself) to the monitoring 
and diagnostic service center 20 over the communication links previously 

25 described. The portable unit 14 and its visual interface replace the prior 
art paper-based information, thereby simplifying and expediting the 
repair process. Upon completion of the repair, the portable unit 14 
generates a feedback report describing the nature of the problem and the 
repair actions taken. This report is sent to the monitoring and diagnostic 



10 



service center 20, where it will be included with the repair history for that 
locomotive. 

It will be appreciated that the present invention provides the 
technician with essentially all the information he needs to effectively 
5 conduct the diagnosis and repair procedures, relying on information that 
is transmitted from sources distant from the repair site. Having all this 
information available, including help from repair experts, avoids the use of 
paper copies, and ensures a quick and accurate diagnosis and repair of the 
locomotive 12. Further, via the portable unit 14, the technician can 

10 request individualized expert assistance from the diagnostic service center 
20 when problems or issues arise that he is incapable of handling. 

The monitoring and diagnostic service center 20 is operated by 
~ personnel who are experts in trouble shooting railroad locomotives. 

Information received about the locomotive 12 from the portable unit 14 

15 can be electronically processed and then visually displayed to these repair 
experts. The repair expert analyzes the information and produces a 
recommendation identifying the potential root cause or root causes of the 
problem. The repair information is then delivered to the portable unit 14 
for execution of the recommended actions in a timely fashion, providing an 

20 enhanced degree of accuracy in carrying out the repair procedure. 

There are at least three different classes of maintenance procedures 
that may be performed on the locomotive 12. The first are predictive in 
nature. That is, based on information downloaded from the locomotive 12, 
experts at the monitoring and diagnostic service center 20 determine that 

25 a given component of the locomotive may be on a path toward eventual 
failure. It is important for the technician to replace this component to 
avoid a locomotive failure while it is in operation. The second class of 
maintenance procedures are those that are planned in advance to occur on 
a predetermined schedule. These are otherwise known as planned 

30 maintenance. Planned maintenance can be based on, for example, the 
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number of locomotive service hours or the number of miles it has traveled 
since the last maintenance action. Again, the objective is to avoid failure 
during locomotive operation. In-service failures are especially costly and 
inefficient for railroad operations, because the locomotive and the train 
5 consist may have to be moved back to a service facility to undertake the 
required repairs. Clearly, this is an expensive and disruptive effort for 
railroad operations. Finally, the last repair class is those maintenance 
problems requiring immediate attention due to a component failure that 
disables or causes derating of the locomotive. With regular and timely 

10 predictive and preventive maintenance, the number of maintenance 
actions in the third category can be minimized. 

Although not illustrated in Figure 1, it is well known in the art that 
the locomotive 12 may have an on-board monitoring system for monitoring 
and recording data related to various operational aspects. The on-board 

15 monitoring system identifies faulty components and provides fault codes 
for use by the repair technician in diagnosing the problem. Also, the on- 
board monitoring system records the number of miles traveled, the 
amount of fuel consumed, the number of service hours, etc. In some 
locomotives, there may be more than one on-board monitoring system, 

20 each associated with different locomotive subsystems. In any case, the 
technician, using his portable unit 14, can access data stored in the on- 
board monitoring system and transmit it to any of the recipient sites 
shown in Figure 1. This operational information may be desirable in the 
diagnostic and repair process. In some cases, depending upon the nature 

25 of the fault or anomalous condition, the on-board monitor automatically 
transmits this information back to the MDSC 20, where a repair 
recommendation is formulated and then made available to the portable 
unit 14, in a manner to be discussed further below. For those locomotives 
that do not have an on-board monitor, the technician may have to directly 

30 extract information from the locomotive 12 and forward this information 
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to the MDSC 20. To extract this information and provide it to the MDSC 
20, the technician may use the video camera or bar code reader in 
conjunction with the portable unit 14, as discussed above. 

Figure 2 is a block diagram illustrating various exemplary 
5 databases and modules to which users, e.g., a technician or any other 
personnel associated with services operations, may have access (directly or 
indirectly) through the portable unit 14. The databases and modules are 
also linked bi-directionally so that the technician can move seamlessly 
from one to the other either manually or automatically through a 

10 hyperlink process whenever the required information is stored in more 
than one location. 

The present invention in one aspect thereof contemplates an 
electronic service delivery system (that is, E-izing) that allows many 
software applications and databases such as those illustrated in Figure 2, 

15 to be available and utilized at the site where a technician is to perform 
diagnosis, maintenance, or repair services on any mobile asset, such as the 
locomotive 12. The present invention provides streamlining and 
standardizing of service information and multiple processes as well as 
providing the technician with all the required information needed to 

20 repair the locomotive 12 on location. 

An interface unit 40 is shown generally for conditioning data 
transferred between the various information sources of Figure 2 and the 
portable unit 14. The interface unit 40 provides data conditioning, 
modulation or demodulation of a carrier signal to transmit or recover an 

25 information signal and signal conditioning for baseband transmission, as 
dependent on the nature of the communications channel. The interface 
unit 40 supports both wired and wireless transmissions and their related 
protocols. Both the portable unit 14 and the MDSC 20 communicate bi- 
directionally with the various databases and modules of Figure 2 for the 
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purpose of entering data into or extracting data from the databases and 
modules. 

An expert repository 42 stores the repair recommendations 
authored at the MDSC 20. These recommendations include: suggested 
5 repairs based on operational and/or failure information extracted from the 
on-board monitoring system of the locomotive derived from symptoms 
reported by the repair technician, or planned maintenance actions, or field 
modifications or upgrades. The recommendation can include suggested 
trouble shooting actions to further refine the repair recommendation and 

10 links to appropriate repair instructions, schematics, wiring diagrams, 
parts catalogs, and trouble shooting guides to make the diagnosis and 
repair process easier. Diagnosis information can be returned to the MDSC 
20 in real time via the portable unit 14 for further analysis in the 
development and refinement of a repair recommendation. At the MDSC 

15 20, expert systems, artificial intelligence tools, and case-based reasoning 
tools are used to develop the specific repair recommendations stored in the 
expert repository 42. These tools are discussed in greater detail in the 
commonly owned patent application entitled "Apparatus and Method for 
Performance and Fault Data Analysis" bearing patent application number 

20 09/629,597, filed on July 31, 2000, (Attorney docket number 
624226. 144/20-LC- 1974, 1975, 1976, 1998). For locomotives having an 
onboard monitor that generates a specific code for a specific operational 
fault, that code can be used to retrieve relevant diagnosis and repair 
information from the expert repository 42. The expert repository 42 can 

25 also include special procedures providing the technician with up-to-date 
procedures for performing certain tasks on the locomotive 12. 

An operational parameter database 44 is the storage site for the 
operational data and information items that are transmitted between the 
monitoring and diagnostic service center 20 and the locomotive 12. The 

30 transmitted information, which is continually updated as new information 
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is received, includes: fault codes, repair action feedback, repair action 
analysis, inspection results, operational information, and repair schedules. 
After recommendations are prepared at the MDSC 20, they are stored in 
the operational parameter database 44, while awaiting transmission to 
5 the portable unit 14 for implementation. Operation parametric trending 
information is also stored within the operational database 44. The trends 
can calculated by comparing operational values over a period of time and 
comparing those values with historical data or nominal data for similar or 
identical locomotives. 

10 An inspection information database 46 stores information indicating 

planned inspection dates for the locomotive 12. The inspection schedule is 
unique to each individual locomotive, based on the locomotive 
identification or road number. When a locomotive is due for inspection, 
the appropriate inspection procedures, stored in the inspection 

15 information database 46, are transmitted to the portable unit 14. In one 
embodiment, the repair procedure includes feedback boxes for each 
inspection step. These feedback boxes are completed by the technician 
and automatically generate a summary inspection report that is saved in 
the repair information database 46 or printed for filing. Procedures for 

20 performing rail car and daily locomotive inspections are also stored in the 
inspection information database 46. 

The inspection information database 46 further includes a wizards 
module to aid the inspection process. The wizards, which include 
standard inspection processes to identify locomotive problems, present the 

25 inspection process in a step-by-step procedure that eliminates guesswork 
on the part of the technician. Further, the technician is able to choose the 
order in which the inspection is conducted only if the individual inspection 
tasks are not interdependent. The wizards module further provides access 
to technical information in the expert repository 42 as necessary. In 

30 addition to the inspection wizards, maintenance wizards walk the 
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technician through maintenance processes that need to be carefully 
controlled to ensure a quality result. The steps of the maintenance 
wizards are integrated with a repair or maintenance work order and may 
further utilize back-end information (i.e., e-training, technical manuals 
5 and schematics). The maintenance wizards also provides access to trouble 
shooting wizards as appropriate. The trouble shooting wizards isolate a 
problem to a specific part and then create a work order for the repair of 
that part. 

Using the portable unit 14, the technician can enter a locomotive 

10 identification number or road number to retrieve a history of past repairs 
from a locomotive history database 50. A feedback feature associated with 
each repair task prompts the technician to enter certain information as 
repair steps are completed. This information is captured at the MDSC 20 
and stored in the locomotive history database 50 to create a parts usage 

15 history and a record of the repair tasks completed. For example, a serial 
number and a description of each part used during a repair is retained 
within the locomotive history database 50. Each repair task has an 
appropriate closing code. The technician closes the repair using the 
appropriate code, after which the locomotive can be returned to service. 

20 The locomotive history database 50 includes three classes of repair: 
repairs not started, repairs in progress, and closed repairs. 

Additional information available to the technician resides in a 
maintenance planning and scheduling database 52. Using this database, 
the technician can access railroad shop management tools and generate 

25 and modify locomotive maintenance and repair work orders and schedules. 
The technician can also access standard work orders and procedures and 
adapt them as necessary to a specific locomotive. Information concerning 
repairs in progress is also available in the maintenance planning and 
scheduling database 52, on a real time basis. Information about a specific 

30 locomotive's "health" is available from the maintenance planning and 
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scheduling database 52 by checking the pending and forecast inspections 
and repairs. Pending repair or maintenance work orders stored in the 
maintenance planning and scheduling database 52 include an estimated 
repair time and the site where the repair is to be performed. Further, 
5 each standard repair process is assigned a repair code and each repair 
code has an associated repair time estimate. Collectively, this repair time 
information aids the railroad management with scheduling locomotives for 
return-to-service. The maintenance planning and scheduling database 52 
further includes a safety-on-the job module providing easy and fast access 
10 to online safety rules and procedures. 

The locomotive repair technicians have quick and easy access to 
accurate locomotive hardware and software version configurations via a 

! configuration management information database 54. The hardware and 

software elements incorporated into a locomotive can be different, even 

= 15 within the same locomotive model. Thus, each locomotive is uniquely 
identified with a road number and the configuration management 
information database 54 allows retrieval of configuration information 
based on the unique locomotive road number. The technician needs 
accurate knowledge of the locomotive configuration before undertaking a 
20 diagnosis or repair. Heretofore, configuration information has been 
generally available only in paper form, and given the complexity of a 
railroad locomotive, the amount of paper describing the locomotive and its 
particular hardware and software configuration can be substantial, and 
difficult to manage and utilize. Also, the configuration management 
25 information database 54 advises the technician when software or 
hardware changes are required to upgrade the locomotive to the most 
recent configuration. The configuration management database 54 also 
includes all field modifications which alert the technician to suggested or 
mandatory modifications, including instructions for performing them for 
30 each locomotive, as issued by the locomotive manufacturer. 
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The configuration management database 54 also validates software 
application prior to loading into a specific locomotive 12. That is, if the 
software version is not compatible with other hardware or software 
components of the locomotive 12, approval for integration will not be 
5 granted. The configuration management database 54 can further identify 
the locomotive for which new software versions apply and can generate a 
work order for implementing that software version into the locomotive 12. 
As a result, software version incompatibility problems are avoided. 

A repair information vault 56 includes a homepage address (e.g. a 

10 universal resource locator) for each repair code, with a link to repair 
instructions, schematics, parts catalogues, back shop manuals, operating 
manuals, drawings, trouble shooting guides, fault analysis manuals, 
maintenance manuals, video clips, still photographs, audio instructions, 
etc. All information in the repair information vault 56 is key word 

15 searchable by the technician (to avoid page-by-page searching), and all the 
data is linked (much like World Wide Web hyperlinks) for ease in 
navigating and locating the appropriate information. For example, 
acronyms and part numbers are linked to the applicable catalog in the 
parts-ordering module 58 discussed below. Retrieval of the technical 

20 documentation in the repair information vault 56 can be further limited to 
portions of a larger document to avoid overwhelming the technician with 
too much information. The repair information vault 56, in one 
embodiment, includes a road number navigator to provide a searchable 
field for retrieving relevant information stored within the information 

25 vault 56 by entry of the locomotive road number. The repair information 
vault 56 further includes a series of online skill-based tutorials ranging 
from the simplest to the most complicated diagnosis and repair tasks. For 
instance, the entry level tutorial may provide overall familiarization with 
the locomotive operating systems and the most advanced level teaches 

30 detailed analysis and diagnostic concepts. 
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The technical documentation included within the repair information 
vault 56 provides quick and easy access via visual- drill-down techniques to 
specific sections of the documentation, as required for a given repair. The 
searchable features offer easy access to specific technical information (e.g., 
torque values) to improve the accuracy and efficiency of repairs. Specific 
repair procedures can also be reviewed to improve the safety of the repair 
process. 

The parts-ordering module 58 is also available to the technician via 
the portable unit 14. There are two types of parts orders: general 
inventory orders and repair orders. An online ordering system, included 
in the parts ordering module 58, allows direct parts ordering for inventory 
or for a specific repair, and access to the railroad's parts inventory to 
determine if the part is already available there. Repair parts ordered for a 
specific repair are matched with the locomotive configuration to ensure 
the correct part is obtained. The parts ordering module 58 also provides 
access to online catalogs issued by suppliers of locomotive components. 
General inventory orders are executed whenever the railroad's inventory 
for a part falls below a predetermined threshold. The parts ordering 
module 58 further includes easy-to-use visual navigation allowing the 
technician to drill down to pictures of a locomotive to pick a specific part 
without knowledge of the part number. Further, the availability of the 
required part is indicated and if available, the part can marked for 
delivery to the service yard 13. 

The parts-ordering module 58 provides electronic inventory 
consumption recording so that inventory can be shipped from the supplier 
to the railroad operator or party responsible for the repair. The parts- 
ordering module 58 is integrated with the maintenance planning and 
scheduling database 52 to insure that parts required for scheduled 
maintenance activities are available in inventory just prior to the 
scheduled maintenance. This technique improves the forecasting of 
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inventory purchases and assures that the parts inventory is maintained at 
an optimum level. Information regarding the number of parts in 
inventory and the location of such parts (for example, in the 
geographically distributed inventory shops maintained by the railroad or 
party providing repair services) is also available in the parts-ordering 
module 58. 

Once parts are ordered, the ordered parts tracking module 60 
allows tracking of all active and historical parts orders for a locomotive, 
e.g., whether shipped on back order and the quantity ordered. The 
tracking function can be driven by the locomotive identification number, 
by the order number or the part number. 

A warranty information module 62 allows access to the applicable 
locomotive warranty documents. By entering a locomotive identification 
number, personnel can view all warranty information about that 
locomotive and its components. Warranty claims can also be submitted 
and tracked via the warranty information module 62. 

A process improvement module 63 provides information and tools 
(such as data warehouse reports) to analyze the effectiveness of the repair 
process and the overall operations at the service shop 16. The process 
improvement module 63 also tracks cycle time for individual maintenance 
steps and for the execution of specific repairs. 

A shop planning and scheduling module 64 provides current 
information and processes to plan the maintenance of a plurality of 
locomotives 12 at the service shop 16 or a service yard 13. The planning 
and scheduling module 64 also includes a monitor board or display for 
identifying the status of the implementation of the service 
recommendations on each locomotive in the service shop 16 or at the 
service yard 13. 

All the databases and modules discussed above are available seven 
days a week and 24 hours a day from the portable unit 14. There is little 
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or no human intervention required to access them, and thus around the 
clock availability is ensured. 

In those embodiments and/or situations where it is necessary for 
the technician to extract information from the locomotive 12, the 
5 technician connects the portable unit 14 to a locomotive interface (e.g., an 
Ethernet connection) to communicate with the locomotive on-board 
monitoring system. The portable unit user interface guides the collection 
of information from the locomotive 12 and also provides memory for 
temporary data storage. Later, the data can be transferred to the railroad 

10 service shop 16 and/or to the monitoring and diagnostic service center 20. 
In one embodiment, the portable unit 14 includes a bar code scanner for 
reading the locomotive identification number, part numbers, and serial 
numbers. Use of a scanner for parts identification ensures accurate 
information feedback to both the parts ordering module 58 and the 

15 ordered parts tracking module 60. In another embodiment the portable 
unit 14 includes a camera for providing visual information back to the 
monitoring and diagnostic service center 20. 

In one embodiment, the portable unit 14 functions as a stand alone 
device, performing the transactions discussed above without physical 

20 connection to a data portal. As shown in Figure 3, the portable unit can 
comprise various styles and configurations, designated by reference 
character 70. The portable units 70 communicate via an RF wireless link, 
with one or more access points 72. The access points 72 is connected to an 
Ethernet hub 74, which then provides connectivity to a host server 76, via 

25 an Ethernet based media 78, employing, for example, the TCP/IP protocol. 
The access points 72 serve as both receivers and transmitters (i.e., 
transceivers) to both receive information from and transmit information to 
the portable units 70, including the information discussed above in 
conjunction with Figure 2. In one embodiment, one access point 72 can 

30 support up to 400 portable units. Various data security measures, 



21 



including encryption can be employed on the communication link. Use of a 
wireless link also allows easy expansion, as the wireless scheme can 
accommodate both small and large wireless networks, and does not 
require running new wires as the network expands. In another 
5 embodiment of the present invention, the portable unit 14 can be 
connected to a data communications line via a wire based medium, such as 
the land-based telephone system, a cellular system or a satellite based 
communication system. Although shown as a relatively simple device 
including a display, the portable unit 14 in other embodiments, may 

10 include a full size monitor, a key board, mouse, printer and/or other 
related input/output devices for enabling and expanding the interaction 
between the technician and the portable unit 14. Information is 
conveniently displayed on the portable unit 14 at the click of a mouse, the 
touch of a screen, a voice command, etc. dependent upon the specific 

15 operational features of the various portable units 70 illustrated in Figure 
3. In one embodiment, the portable unit 14 comprises a handheld ViA 
computer, loaded with the appropriate software applications, available 
from ViA, Inc., of Burnsville, Minnesota. 

The portable unit 14 also offers an instant messaging feature 

20 allowing the technician to quickly communicate repair information (for 
example, fault codes, diagnostic readings, or simple descriptive text) to a 
repair expert at the monitoring and diagnostic service center 20. The 
repair expert can respond directly to the technician through the portable 
unit 14. This feature is intended for use during the collection of additional 

25 diagnostic information or when problems are encountered during the 
course of a repair. 

The portable unit 14 includes a graphical user interface. An 
exemplary screen is shown in Figure 4. The information is presented in a 
clear and concise style so that users with all ranges of experience can 

30 adequately use and understand the displayed information. The portable 
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unit 14 offers short cut links to commonly used data and functions for 
experienced users, with more detailed instructional links for less 
experienced users. The portable unit 14 also has a back-out feature to 
move from the current screen to the previous screen, in this way leaving 
5 the user with no dead ends. Regardless of the locomotive that is 
undergoing repair, all applications and information on the portable unit 14 
and all file formats, (no matter there origin from one of the many 
databases illustrated in Figure 2) utilize the same presentation format 
and in this way their source will be transparent to the technician. 

10 Figures 5 and 6 are flow charts showing exemplary steps that may 

be involved in implementing a service recommendation according to one 
aspect of the present invention. Typically, the service recommendation is 
a recommendation for a repair, but the teachings of the present invention 
are not so limited. Service recommendations can also involve maintenance 

15 procedures or diagnostic processes with the objective of finding the root 
cause for a fault or anomalous condition. At a step 100, a technician 
arrives at the service yard 13 where the locomotive is parked. The 
technician retrieves his portable unit 14 (step 102) and signs on at a step 
104. At a step 106, the technician enters the locomotive road number or 

20 other locomotive identification number, which is transmitted to the service 
shop 16. Figure 5 illustrates this transmission through a wireless 
arrangement, although as will be appreciated by those skilled in the art, 
there could also be a wire-based connection between the portable unit 14 
and the service shop 16. The service shop 16 may then establish a 

25 communications connection with the customer center 24 and/or the MDSC 
20. The portable unit 14 queries the MDSC 20 for information for the 
locomotive road number entered at the step 106. The technician may 
request any of the items discussed in conjunction with Figure 2, such as 
repair or maintenance information, historical repairs, etc. Once the 
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requested information is received at the service shop 16, it is sent to the 
portable unit 14, as illustrated at a step 108. 

Information sent from the portable unit 14 to the MDSC 20 includes 
problems with a locomotive, the current status of locomotive systems, 
5 repair requests, diagnostic information and video clips and still 
photographs. Locomotive problems may be observed directly by the 
technician or downloaded from the locomotive on-board monitoring system 
as previously discussed. Information returned to the portable unit 14 from 
the customer center 24 and the MDSC 20 includes recommended repairs 

10 and relevant technical documentation required to perform the repairs as 
discussed in conjunction with Figure 2. This information is displayed on 
the portable unit 14 to allow the technician to accurately and quickly 
repair the locomotive. The information displayed on the portable unit 14 
includes a pictorial view of the locomotive and its constituent parts, repair 

15 steps, technical documentation relevant to the repair, and the tools 
necessary to perform the repair. Assembly diagrams and assembly 
instructions are also displayed. Multimedia information, such as video 
clips or audio instructions can also be transmitted to the portable unit 14 
from the MDSC 20. In short, all information discussed in conjunction with 

20 Figure 2 is immediately available to assist the technician with diagnosis, 
repairing and/or servicing of the locomotive. 

Continuing to Figure 6, a step 120 represents the technician's 
execution of the repair or service task. A decision step 122 asks whether 
the repair has been completed. When completed, processing continues to a 

25 step 124 where the locomotive is signed out from the repair site, either the 
service yard 13 or the service shop 16. At a step 126, release procedures 
are executed, after which the locomotive is returned to service. The 
release procedures involve confirming that all necessary steps required for 
return to service have been completed and generating a notice to railroad 

30 operational personnel that the locomotive 12 is ready to return to service. 
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If the repair has not been completed at the decision step 122, 
processing continues to a decision step 128, where inquiry is made as to 
whether a new part is needed to complete the repair. If a new part is not 
required, processing continues to a step 130 to determine why the repair 
5 has not been completed. For example, there may have been a work-force 
shift change during the repair process. In any case, the reasons why the 
repair has not been completed are communicated to the service shop 16 by 
the technician via the portable Unit 14. 

If a new part is needed, processing moves from the decision step 128 

10 to a parts requisition step 132, where, the portable unit 14 communicates 
with the service shop 16 to requisition the part. A step 134 is executed for 
those parts that must be ordered from a third party supplier, via the parts 
requisition center 22. As illustrated by step 136, once the part has been 
ordered, the technician can continue the diagnostic and repair process for 

15 another locomotive or perform another repair on the current locomotive. 

The electronic data delivery system of the present invention 
provides in one aspect thereof an improvement in the diagnosis, repair 
and maintenance of a mobile asset such as the locomotive 12 by applying 
E-business technologies to replace the prior manual paper-based 

20 processes. A benefit derived from applying these technologies includes 
improved availability of the mobile asset by reducing the cycle time of the 
repairs and more efficient and focused repair processes. Additionally, by 
using the various databases and modules illustrated in Figure 2, the many 
processes related to a repair operation will be measurably improved in 

25 accordance with the teaching of the present invention. 

The diagnosis and repair system 140, the portable unit server 141, 
and the portable unit 14, constructed according to aspects of the present 
invention are illustrated in Figure 7. While Figure 2 diagrammatically 
illustrates the individual databases and information sources accessible to 

30 the portable unit 14, Figure 7 depicts aspects of the present invention 
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from the system/subsystem level. The diagnosis and repair system 140 
includes a recommendation authoring system 182, a repair status system 
184, a technical documentation system 186, and the interface unit 40, 
previously discussed in conjunction with Figure 2. With reference to the 
5 individual databases and information sources shown in Figure 2, the 
recommendation authoring subsystem 182 includes the expert repository 
42 and the operational parameter database 44. The repair status 
subsystem 184 includes the locomotive history database 50, the 
maintenance planning and scheduling database 52, the repair information 

10 vault 56, and the inspection information database 46. As suggested above, 
the diagnosis and repair system 140 may communicate with the portable 
unit 14 via the portable unit server 141. The communication link between 
the portable unit server 141 and the interface unit 140 can be either wired 
or wireless. Likewise, the portable unit 14 communicates (using either a 

15 wired or wireless media) with various components aboard the locomotive 
12. In particular, the portable unit 14 extracts data from and provides 
data to an on-board monitoring system 194. Also, the portable unit 14 can 
query other locomotive subsystems, shown generally by a reference 
character 196. 

20 The recommendation authoring subsystem 182 provides the 

functionality for authoring general repair recommendations and 
instantiating specific recommendations for a locomotive. The 
recommendation authoring system 182 provides the following exemplary 
functions: defining the steps involved in a repair, specifying the relevant 

25 technical documentation to accompany the repair recommendation and 
specifying the data that needs to be collected by the technician to execute 
the repair. The repair recommendation, instructions, and data to be 
collected are compiled into a cohesive deliverable package that is 
eventually delivered to the portable unit 14. In one embodiment, the 

30 compiled information is provided as a web formatted package. By using a 
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web format (or other standardized format) the information can be 
displayed on the portable unit 14 in a standard format with which the 
technician will eventually become familiar. Consistency and familiarity 
with the repair information format allows the technician to efficiently 
5 navigate through the information provided and in this way increase his 
productivity. One feature of the recommendation authoring subsystem 
182 is the creation of rep air- specific process steps (including all relevant 
technical documentation necessary to execute each step) for the 
technician. Using all the general diagnosis, repair and technical 

10 information available, the recommendation authoring subsystem 182 
selects only that information needed for a specific repair as associated 
with a specific locomotive based on a unique locomotive designator, such 
as the road number, and presents this to the technician. With repair- 
specific information and back-up technical documentation readily 

15 available, the technician can more easily and efficiently execute the repair 
process. 

The repair status subsystem 184 maintains and provides 
information on the status of a repair. This information is based on 
feedback provided by the technician during and after completion of the 

20 repair. The technical documentation subsystem 186 maintains the 
technical documentation for the locomotives and supports the selection 
and retrieval of the appropriate technical documentation into a repair- 
specific set of relevant technical documentation. 

The portable unit server 141 disseminates repair instructions to the 

25 portable units 14 and collects information from those units. Although only 
one portable unit 14 is shown in Figure 7, it will be understood that the 
portable unit server 141 can communicate with many portable units 14, as 
shown in Figure 3. It is expected that each technician or team of 
technicians with service or repair responsibility will have a portable unit 

30 14. The functionality provided by the portable unit server 141 includes: 
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serving as a communications link to the interface unit 40, connecting with 
and identifying each portable unit 14 at power up, transferring feedback 
files from the portable unit 14 to the diagnosis and repair system 140, 
transferring the repair recommendations and relevant technical 
5 documentation to the portable unit 14, synchronizing clock times, 
validating the identity of the technician using the portable unit 14 and 
clearing files from the portable unit 14 once these files have been 
transferred to the portable unit server 141. In one embodiment of the 
present invention, the portable unit 14 can communicate directly with the 

10 diagnosis and repair system 140, thus rendering the portable unit server 
141 unnecessary. In such an embodiment, the tasks performed by the 
portable unit server 141 are performed by the diagnosis and repair system 
140 and/or by the portable unit 14. 

The portable unit 14 displays the repair instructions to the repair 

15 technician and creates a record of the service event. Among the functions 
of the portable unit 14 are: providing a log in and log out interface, 
displaying repair instructions and all supporting technical documentation 
(including multimedia information), accepting repair feedback information 
and updating the repair feedback file when a repair action is finished and 

20 communicating with the locomotive 12 to extract information from the on- 
board monitoring system 194 and the other locomotive subsystems 196. 

In one exemplary embodiment, a principal function of the 
recommendation authoring subsystem 182 is to select general repair 
recommendations from the various sources available within the diagnosis 

25 and repair system 140 and to transform this information into a set of 
locomotive-specific, repair-specific instructions and relevant 
documentation. The recommendation and authoring subsystem 182, in 
one embodiment, is located at the monitoring and diagnostic service 
center 20. A general repair recommendation is those repair actions (i.e., a 

30 sequence of steps to be performed by the technician to execute the repair) 
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that are responsive to a given set of fault codes. These fault codes are 
downloaded by the portable unit 14 from the on-board monitoring system 
194 and the other locomotive subsystems 196, and provided to the 
recommendation authoring subsystem 182. The fault codes may also be 
5 communicated directly and automatically to the MDSC 20 from the on- 
board monitor, as discussed in detail in the aforementioned patent 
application entitled "On-Board Monitor for a Railroad Locomotive". In the 
present invention, the general repair recommendations are instantiated 
into a specific repair recommendation for a given fault that has occurred 

10 on a specific (i.e., road number) locomotive 12. A user display 187 is 
responsive to the recommendation authoring subsystem 182 for use by the 
repair expert 142 in formulating the repair recommendation. 

The technical documentation available to the recommendation and 
authoring subsystem 182 includes parts catalogs, maintenance manuals, 

15 schematic diagrams, fault code listings, and back shop manuals, and 
various multimedia files, such as video or audio instructional materials. 
This information represents typically-recommended documents needed for 
a repair. Specific pages and excerpts from this generalized documentation 
are identified by the recommendation authoring subsystem 182 when the 

20 recommendation is instantiated for a particular locomotive repair. 

In one exemplary embodiment, the recommendation authoring 
system 182 interfaces with the technical documentation subsystem 186 to 
locate technical documentation and multimedia presentations relevant to 
the recommendation. The recommendation authoring system 182 provides 

25 search criteria to the technical documentation subsystem 186 for 
retrieving relevant documentation. Included within the search criteria are 
one or more of the following: part name, part number, action name, repair 
fault code, and locomotive model. Search scope information is also 
provided to the technical documentation subsystem 186 for specifying 

30 where to look for relevant documentation. Included within the search 
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scope are parts catalogs, maintenance manuals, schematics, back shop 
manuals, fault analysis pages, field modification instructions, and 
multimedia files. In response to the inputs, the technical documentation 
subsystem 186 responds to the recommendation authoring system 182 
5 with the location of the technical documentation that satisfies the search 
criteria. The output is a list and each entry in the list contains the 
following information about that entry: location of the page (for 
subsequent retrieval), size of the file making up the page, the type of page 
(i.e., the document source), and the locomotive road number or numbers to 

10 which the page applies. 

Another interface between the recommendation authoring 
subsystem 182 and the technical documentation subsystem 186 provides 
access to a browsing mechanism within the technical documentation 
subsystem 186. This browsing mechanism allows the repair expert to 

15 review the documentation pages to determine if it is necessary to refine 
the search criteria. 

As illustrated in Figure 7, the recommendation authoring 
subsystem 182 also interfaces with the repair status subsystem 184. The 
recommendation authoring subsystem 182 allows selection of existing 

20 general repair recommendations for a specific problem or repair code. 
Also, the recommendation authoring subsystem 182 inputs a summary of 
the repair recommendation to the repair status subsystem 184 so that the 
latter can create an entry in the repair status database for each repair. 
The repair status subsystem 184 responds to the recommendation 

25 authoring subsystem 182 when the repair entry is created. The 
transmitted summary includes: the repair case number, the date and time 
that the recommendation was issued, the road number to which it applies, 
the steps outlined in the repair recommendation, the technical 
documentation to accompany each repair step, and the repair status. The 

30 recommendation authoring subsystem 182 also provides to the repair 
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status subsystem 184 the data store locations for the data entry objects. 
The purpose of this input is to ensure that the data store locations are 
recognizable by the repair status subsystem 184. 

The repair status subsystem 184 also supplies a list of possible 
5 locations for storing the values collected by the data entry objects. The 
repair status subsystem 184 stores these values when they are received 
following an actual repair event, as part of the repair feedback process. 

The technical documentation subsystem 186 maintains the 
technical documentation repository and supports the selection and 

10 retrieval of technical documentation into a repair specific set of relevant 
documents by the repair expert. In one embodiment, the technical 
documentation is available in a web-based format. The technical 
documentation subsystem 186 supports the retrieval of individual pages or 
sections from technical documents, rather than retrieval of the entire 

15 document. The technical documentation is also indexed. These indexes 
provide quick identification of document subsets. For example, the indices 
can support identification of all documentation pages related to a specific 
part number, a specific part name, or a repair process name. All relevant 
technical documents are stored in the technical documentation subsystem 

20 186. The stored documents are: parts catalogs, wiring and parts 
schematics, maintenance manuals, fault analysis pages, back shop 
manuals, field modifications instructions, training instructions, part 
identification animations, assembly animations, etc. The documentation 
includes both text, graphics, and visualization based documents. 

25 Thumbnail style summaries may be included with each document. 

The files of the technical documentation subsystem 186 can be 
remotely browsed. That is, a user logged in to a network computer 
connected to the diagnosis and repair system 140, but not necessarily the 
equipment hosting the technical documentation subsystem 186, can search 



31 



for pages, view pages, follow links between pages, and copy pages to a local 
file. 

The technical documentation subsystem 186 supports a search 
mechanism based on one or more of the following criteria: part name, part 
5 number, action name, fault code, locomotive model, and document type. 
Search results are presented in the form of a summation of the search 
results, with pointers to the actual pages so they can be retrieved on 
demand. The technical documentation subsystem 186 also supports the 
retrieval of individual document pages or document sections from its files. 

10 The retrieval process copies the retrieved pages to the user's application. 
The retrieval mechanism automatically adjusts hyperlinks between the 
copied pages accordingly. 

The technical documentation subsystem 186 receives two types of 
inputs from the recommendation authoring system 182. These include 

15 search criteria and search scope. Search criteria refers to one or more of 
the following: part name, part number, action name, fault code, or 
locomotive model number. The search scope refers to parts catalogs, 
maintenance manuals, schematics, back shop manuals, fault analysis 
pages, and field modification instructions. 

20 The output from the technical documentation subsystem 186 is the 

list of all the technical documentation pages satisfying the search criteria. 
Each entry contains the following: the location of the page (for subsequent 
retrieval), the size of the file that makes up the page, the type of page 
(that is, the document source), and the locomotive road numbers to which 

25 the page applies. The recommendation authoring subsystem 182 can also 
access the technical documentation subsystem 186 for generalized 
browsing of the files. This feature allows a user to browse the 
documentation pages to determine the appropriate search criteria to use. 
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In one exemplary embodiment, the portable unit server 141 may 
use the following data concepts: specific recommendation directories, user 
identity files, portable unit status databases and home page files. 

The recommendation directory is the location of web-deliverable, 
5 linked packages of repair instructions and technical documentation 
(including multimedia files) provided by the diagnosis and repair system 
140 for each repair recommendation. This information is transferred to 
the portable unit server 141 and filed there. Each recommendation 
directory has a standard file format and architecture that allows the 

10 portable unit server 141 to read summary information about the repair 
recommendation. 

Each repair home page begins with a summary of the repair steps 
and their corresponding feedback or data entry objects. From these 
original repair actions, the technician can drill down to more detailed 

15 information about the repair steps via links. In one embodiment, there is 
always a one-click path back to the original repair action from the deeper 
links. Once the repair step has been completed and appropriate feedback 
information obtained and recorded, the next step in the repair process is 
displayed, with links again to supporting documentation. 

20 The user identity file, used by the portable unit server 141 as a data 

concept, contains names of all technicians registered to use the portable 
units 14. When a technician logs on, the identity entered in the log in box 
is checked against the identities stored in the portable unit server 141. If 
the identification is not in the file, the technician is asked to re-enter the 

25 identification information. The portable unit server 141 also includes a 
portable unit status database containing information about the 
deployment of each portable unit 14. 

In one exemplary embodiment, each repair recommendation may 
have a structure that includes the following data: the recommendation 

30 identification number, the recommendation status, the technician 
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identification number, the portable unit identification number, the log in 
time when the repair began, and the log out time when the repair was 
finished. Each repair recommendation has a file containing this 
information. 

5 The last data element used by the portable unit server 141 is the 

home page list of recommendations. The home page list is the initial file 
displayed on the portable unit 14 when a technician logs on. The home 
page file includes a list of the currently active recommendations with: the 
locomotive road number, the repair technician identification number, the 

10 repair status, and a short description of the repair. A technician selects a 
specific recommendation from the home page file for transfer to his 
portable unit 14, at which time the specific recommendation directory is 
transferred to the portable unit 14. Whenever any data related to an 
active repair recommendation is changed, the home page file is 

15 automatically modified to reflect the change. 

The repair status subsystem 184 (see Figure 7) maintains and 
provides information on the status of each repair. Instantiating a repair 
recommendation triggers the creation of an entry in the locomotive history 
database 50 of the repair status subsystem 184. The locomotive history 

20 database 50 is updated with data values collected by the data entry objects 
during a repair operation. Each repair entry in the locomotive history 
database 50 supports the following data items: repair case number, 
railroad case number, locomotive road number, the date the 
recommendation was issued, the rail yard where the repair was 

25 performed, and a list of the rail yard personnel who worked on the 
recommendation. Each repair entry also includes the data values 
collected with each step, the date the repair step was performed (as 
derived from the data collection process), and the current repair status 
(e.g., none, active, halted, or complete). 
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A new repair status entry is created in the repair records database 
50 of the repair status subsystem 184 as follows. When a new 
recommendation is instantiated in the recommendation authoring 
subsystem, a summary is passed to the repair status subsystem 184. This 
action triggers the creation of an entry in the repair records database 50 
for the recommended repair. If a recommendation for a given case number 
is instantiated multiple times, the repair status subsystem 184 maintains 
the latest version of the recommendation. The repair status subsystem 
184 maintains the most recent feedback irrespective of the version of the 
recommendation. 

As discussed above, there is a considerable amount of technical 
documentation available to the technician using the portable unit 14. The 
technician can navigate or search through the technical documentation by 
using wizard applications or visual drill downs. Additionally, the 
technical documentation includes on-line tutors that can be used to 
enhance the technician's understanding of the structure and function of 
the locomotive. The tutors are available in various levels of difficulty. 

Figure 8 is an exemplary flow chart illustrating an example of a 
trouble shooting wizard 251. More specifically, this flow chart illustrates 
the steps involved in checking one specific system, the Crankcase Over 
Pressure ("COP") 301, in a selected equipment, such as a locomotive 12. 
Once started, step 300, a decision gate, step 302, determines whether 
faults are logged. If faults are logged, then a locomotive repair technician, 
or user, will check engine oil level, step 304. The user will determine 
whether the engine oil level is overfull, step 306. If overfull, the user will 
drain the oil to the proper level, step 308. If not overfull, the user will 
check a sensor/device and replace if a defective Diagnostic Interactive 
Display (DID) panel pressure reading is detected, step 310. Next, the user 
will check for water in a crankcase and remove an oil fill cap to look for 
water or emulsified oil, step 312. The user will then determine whether 
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water is in the oil, step 314. If water is in the oil, the user will pressure 
test the engine to identify water leaks, step 316. The user will then 
determine whether leaks are found, step 318. If leaks are found, the user 
will make repairs, step 320. The user will then apply a manometer to the 
5 crankcase and check vacuum/pressure, step 322. In a locomotive, as an 
exemplary example, this check is done at maximum throttle, such as notch 
8 full horsepower. If faults are not logged, step 302, water is not found in 
the oil, step 314 or leaks are not found, step 318, the user will also apply 
the manometer to the crankcase and check vacuum pressure, step 322. 

10 The user will determine whether the pressure is greater than a given 
level, as an exemplary example is pressure greater than 0.24 inches of 
water column pressure, step 324. If not greater than the given level, the 
unit is released, step 326. If the pressure is greater, the user will inspect 
the crankcase eductor tubes and hoses for leaks or worn hoses, and inspect 

15 a muffler eductor tube for blockage or inner tube and remove, step 328. 
The user will then determine whether repairs are required, step 330. If 
required, the user will make repairs, step 332, and then repeat applying 
the manometer to the crankcase and check the vacuum pressure. If no 
repairs are required, the user will inspect a coalescer screen for proper 

20 application and verify that it is not plugged, step 334. The user will then 
determine whether repairs are required, step 336. If repairs are required, 
the user will make the repairs, step 332 and then apply the manometer to 
the crankcase again and check vacuum pressure, step 322. If repairs are 
not required, the user will inspect power assemblies for blow by into the 

25 crankcase, step 338. The user will then determine whether a blow by is 
found, step 340. If a blow by is found, the user will replace the defective 
power assemblies, step 342 and then again apply the manometer to the 
crankcase and check the vacuum pressure, step 322. If a blow by is not 
found, the user will consider that a turbo may have failed seals, step 344, 
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and then inspect or replace the turbo, step 346. The user will then apply 
the manometer to the crankcase and check the vacuum pressure, step 322. 

Figure 9 shows a flow chart of a computerized method for guiding 
equipment service personnel while at an equipment site through a 
plurality of tasks for troubleshooting the health of a selected system of a 
selected equipment to determine the nature and extent of service needed. 
Subsequent to start step 200, step 202 allows to provide a database 
comprising detailed data for health assessment and servicing of a selected 
equipment and system thereof, and an expert rule-based troubleshooting 
wizard for eliciting information regarding the selected equipment and 
system and for providing troubleshooting instructions to determine the 
nature of the equipment fault and the servicing required for the selected 
equipment and system. An input/output device for communicating with 
the database is provided, step 204. The method allows to select the 
equipment and the system thereof to be serviced, step 206. The method 
next provides, step 210, in response to a set of prompts to the personnel 
from the troubleshooting wizard at least one set of observations selected 
from the group comprising operational performance of the selected 
equipment, operational performance of the selected system, and fault 
indications detected in the equipment and system. The method then 
processes, step 212, the observation information relative to the 
troubleshooting wizard to determine whether or not the selected 
equipment and system needs to be serviced, and if so the nature and 
extent of that service. 

Figure 10 illustrates elements used in a computerized system for 
guiding equipment service personnel while at an equipment work site 
through a plurality of tasks for troubleshooting the health of a selected 
system of a selected equipment to determine the nature and extent of 
service needed for such a system. A database 250 is provided which 
comprises detailed data for health assessment and servicing of a selected 



37 



equipment 12 and system 301 thereof. The database also includes an 
expert rule-based troubleshooting wizard 251 for eliciting information 
regarding the selected equipment and system and for providing 
troubleshooting instructions to determine the nature of the equipment 
fault and the servicing required for the selected equipment and system. 
An input/output device 252 is located at the work site for communicating 
with the database and in selecting the equipment and the system thereof 
to be serviced. A data management module 256 is provided for accessing 
the database to interface with the troubleshooting wizard for the selected 
equipment and system. The data management module 256 will supply, in 
response to a set of prompts to the personnel from the troubleshooting 
wizard, at least one set of observations selected from the group comprising 
operational performance of the selected equipment, operational 
performance of the selected system, and fault indications detected in the 
equipment and system. The system also includes a processor 260 
configured to process the observation information relative to the 
troubleshooting wizard 251 to determine whether or not said selected 
equipment 12 and system 301 needs to be serviced, and if so the nature 
and extent of that service. 

Figure 11 illustrates an exemplary work-flow module 500 
embodying aspects of the present invention to control various processes 
associated with implementing a repair or service recommendation. The 
first step of the work order module 500 is the development of a work scope 
at a step 502. The development of the work scope is influenced by certain 
tasks and processes input to a work order. For example, a repair 
recommendation 504, locomotive specific information 506, railroad specific 
information 508, field modification instructions and other 
recommendations requiring implementation 510 and an inspection wizard 
512, the use of which may identify and add additional items to the work 
scope 502. The work scope information is input to a work order backbone 
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520 for creating a work order to implement the various tasks associated 
with the work scope 502. In preparing the work order, the cycle time 
associated with each task must be considered. Additionally, consideration 
must be given to sequencing available locomotives for repair. This 
information is also input to the work order backbone 520 from a step 522. 
Factors that influence the repair schedule include material availability as 
indicated by a step 524 and the availability of other required resources, 
such as the availability of technicians to implement the repairs as 
indicated by the reference character 526. 

Following the sequencing step 522, the work order is activated and 
execution of the repair initiated as indicated by a step 528. The technician 
is directed during the execution of the repair through the portable unit 14 
as discussed above. The information displayed on the portable unit 14 
directs the step-by-step activities of the technician through the repair 
process including providing documentation and information from the 
various databases and modules discussed in conjunction with Figure 2. 
With regard to Figure 8, this information is indicated by a reference 
character 530. The technician also utilizes maintenance troubleshooting 
wizards, identified by a reference character 532 during the repair process. 
Also as discussed above, data entry objects (feedback) are provided by the 
technician as the repair progresses. This information is shown as 
symbolically supplied to the work order backbone 520 and from there 
stored in a data warehouse 534. Real time repair status information is 
provided from the work order backbone 520 to a monitoring board 535, 
which may be located in the service shop 16 or at the service yard 13 for 
providing information on the status of the various in-process repairs. 
Further, information as to the repair processes can be supplied directly to 
a customer either in written form or transmitted electronically for display 
at a customer site, as shown by a reference character 536. Additionally, 
the status information generated by the work order backbone 520 can be 
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reviewed and used to improve the reliability of the various locomotive 
subsystems and further used to improve repair processes across all the 
service shops and service yards operated by the railroad. Communication 
of this status information across the railroad network can be efficiently 
5 accomplished via satellite communications, a land-based system or 
through a cellular telephone network. 

While the invention has been described in what is presently 
considered to be a preferred embodiment, many variations and 
modifications will become apparent to those skilled in the art. 
10 Accordingly, it is intended that the invention not be limited to the specific 
illustrative embodiment but be interpreted within the full spirit and scope 
of the appended claims. 
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